IB - Drop foreign key constraints
Otázka od: Roman Macura
16. 12. 2002 10:53
Ahoj,
delam utilitu pro zmenu struktury databaze podle vzorove databaze s tim,
ze potrebuju zachovat data.
Mam udelany vsechny potrebne kroky, vsechny funguji az jednu malou
"drobnost" -
nejak se mi nedari odstranit vsechny foreign key constraints z databaze
pomoci ALTER TABLE T1 DROP CONSTRAINT FK1;
Pravdepodobne to nedelam ve spravnem poradi, ale
zkousel jsem uz vsechny moznosti, ktere me napadly - pres delphi pomoci
TIBSQL, TIBScript, i start a commit transakce po kazdem mazani, pres
normalni script a IBConsole (najednou i commit po kazdem radku),
poradi mazani jsem zkousel od tech tabulek, ktere maji nejmene vazeb az po
nejvice, potom jsem zkousel mazat
od tech tabulek, ktere nemaji zadne FK rekurzivne podle struktury databaze
(backtracking i po urovnich), ale proste nic.
Po case se zpracovani zastavi na hlasce "INDEX is in use".
Nevite nekdo jak smazat vsechny foreign key constraints z databaze? (IB
6.0.1, Delphi 5, IBX 5.03)
Roman
Odpovedá: Pavel Cisar
16. 12. 2002 17:49
Haj hou!
On 16 Dec 2002 at 10:27, Roman Macura wrote:
> Mam udelany vsechny potrebne kroky, vsechny funguji az jednu malou
> "drobnost" - nejak se mi nedari odstranit vsechny foreign key
> constraints z databaze pomoci ALTER TABLE T1 DROP CONSTRAINT FK1; Po
> case se zpracovani zastavi na hlasce "INDEX is in use".
Znamy problem zpusobeny "problematickou" implementaci DROP CONSTRAINT
(zamek v metadata cache). Pro IB 6 neni jine reseni, ze byt prihlasen
jako jediny uzivatel a po dropnuti FK omezeni se odhlasit a znovu
prihlasit.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Roman Macura
17. 12. 2002 7:08
Myslel jsem si to, diky.
Nemate nekdo nejaky lepsi navrh, jak aktualizovat databazi u zakaznika
na novou verzi struktury (nutnost zachovani dat)?
Prozatim to delame pomoci presunu dat do nove ciste struktury pres SQL.
TIBBatchRawFile bude asi rychlejsi, ale muzu pomoci nej prenest data jedne
tabulky
tvorici strom? (vazba tabulky sama na sebe - prozatim to resime jednou
ulozenou procedurou,
ktera nam vrati zaznamy v odpovidajicim poradi pro spravny insert)...
----- Original Message -----
From: "Pavel Cisar" <pcisar@users.sourceforge.net>
To: <delphi-l@clexpert.cz>
Sent: Monday, December 16, 2002 5:31 PM
Subject: Re: IB - Drop foreign key constraints
> Haj hou!
>
> On 16 Dec 2002 at 10:27, Roman Macura wrote:
>
> > Mam udelany vsechny potrebne kroky, vsechny funguji az jednu malou
> > "drobnost" - nejak se mi nedari odstranit vsechny foreign key
> > constraints z databaze pomoci ALTER TABLE T1 DROP CONSTRAINT FK1; Po
> > case se zpracovani zastavi na hlasce "INDEX is in use".
>
> Znamy problem zpusobeny "problematickou" implementaci DROP CONSTRAINT
> (zamek v metadata cache). Pro IB 6 neni jine reseni, ze byt prihlasen
> jako jediny uzivatel a po dropnuti FK omezeni se odhlasit a znovu
> prihlasit.
>
> S pozdravem
> Pavel Cisar
> Mobil: 724 281429
> http://www.ibphoenix.cz
> Vse co potrebujete pro Firebird a InterBase
>
>
Odpovedá: Martin Schayna
17. 12. 2002 14:40
----- Original Message -----
From: "Roman Macura" <delphi@atlascon.cz>
> Nemate nekdo nejaky lepsi navrh, jak aktualizovat databazi u zakaznika
> na novou verzi struktury (nutnost zachovani dat)?
>
> Prozatim to delame pomoci presunu dat do nove ciste struktury pres SQL.
> TIBBatchRawFile bude asi rychlejsi, ale muzu pomoci nej prenest data jedne
> tabulky
> tvorici strom? (vazba tabulky sama na sebe - prozatim to resime jednou
> ulozenou procedurou,
> ktera nam vrati zaznamy v odpovidajicim poradi pro spravny insert)...
My to resime tak ze tech par cizich klicu "sama na sebe" pridavame
na tabulku az _po_ nahrani dat, napr:
ALTER TABLE Divisions
ADD FOREIGN KEY (Parent_ID) REFERENCES Divisions (ID);
Toto reseni name problemy co popisuje Pavel.
Martin Schayna
Odpovedá: Roman Macura
17. 12. 2002 14:35
Jo, tak to dela i IBPump, je to dobre reseni (sice nevim jak to dela, kdyz
to bez logout/login nejde - jak uz tady bylo psano),
az na to, ze ne pro muj dotaz 
Nemuzu cistou databazi, do ktere bych
prenasel data ze stare, vytvorit ze skriptu
(coz predpokladam delas Ty a pote do-tvoris ty foreign key), protoze nase
vzorova db neni cista, ale obsahuje nejake male mnozstvi dat (bloby, apod.).
Takze kdyz pouziju vzor (existujici db), tak i kdyz nebudu
restrukturalizovat celou db, ale prenaset data,
tak stejne potrebuju udelat drop tech klicu "sama na sebe" a to opet v
jednom pripojeni nejde. To je pekne na h...
Trapný dotaz: Jak narocne bude pro databazi provest 40x login a logout,
abych ty klice v klidu smazal?
Nebo: Lze tedy nejak pracovat s metadata cache, nebo je to fakt marné?
----- Original Message -----
From: "Martin Schayna" <mschayna@aktis.cz>
To: <delphi-l@clexpert.cz>
Sent: Tuesday, December 17, 2002 2:12 PM
Subject: Re: IB - Drop foreign key constraints
----- Original Message -----
From: "Roman Macura" <delphi@atlascon.cz>
> Nemate nekdo nejaky lepsi navrh, jak aktualizovat databazi u zakaznika
> na novou verzi struktury (nutnost zachovani dat)?
>
> Prozatim to delame pomoci presunu dat do nove ciste struktury pres SQL.
> TIBBatchRawFile bude asi rychlejsi, ale muzu pomoci nej prenest data jedne
> tabulky
> tvorici strom? (vazba tabulky sama na sebe - prozatim to resime jednou
> ulozenou procedurou,
> ktera nam vrati zaznamy v odpovidajicim poradi pro spravny insert)...
My to resime tak ze tech par cizich klicu "sama na sebe" pridavame
na tabulku az _po_ nahrani dat, napr:
ALTER TABLE Divisions
ADD FOREIGN KEY (Parent_ID) REFERENCES Divisions (ID);
Toto reseni name problemy co popisuje Pavel.
Martin Schayna
Odpovedá: Martin Schayna
17. 12. 2002 15:18
----- Original Message -----
From: "Roman Macura" <delphi@atlascon.cz>
> Jo, tak to dela i IBPump, je to dobre reseni (sice nevim jak to dela, kdyz
> to bez logout/login nejde - jak uz tady bylo psano),
> az na to, ze ne pro muj dotaz Nemuzu cistou databazi, do ktere bych
> prenasel data ze stare, vytvorit ze skriptu
> (coz predpokladam delas Ty a pote do-tvoris ty foreign key), protoze nase
> vzorova db neni cista, ale obsahuje nejake male mnozstvi dat (bloby, apod.).
Ano, generujeme ji ze skriptu a take do ni nahraveme vychozi data
(i bloby) samozrejme ne pomoci standardniho SQL ale pomoci vlastniho
nastroje ktery umi nahrat data do tabulky z binarniho streamu (muze
proto obsahovat i bloby). Pak nahravame uzivatelska data podobnym
zpusobem avsak se zohlednenim zmen ve strukture. Na zaver se
pripoji prave ty problematicke referencni integrity.
>
> Takze kdyz pouziju vzor (existujici db), tak i kdyz nebudu
> restrukturalizovat celou db, ale prenaset data,
> tak stejne potrebuju udelat drop tech klicu "sama na sebe" a to opet v
> jednom pripojeni nejde. To je pekne na h...
Vzorova databaze je IMHO spatny zpusob, co kdyz ma klient
jiny IB server -- s jinou ODS nebo na jine platforme.
> Trapný dotaz: Jak narocne bude pro databazi provest 40x login a logout,
> abych ty klice v klidu smazal?
> Nebo: Lze tedy nejak pracovat s metadata cache, nebo je to fakt marné?
Podle me budes mit problem -- jinak se chova napr. FB a IB. Na FB
se aplikace uplne odloguje, ale stejne si server databazi (nejakou dobu)
pridrzuje.
Martin Schayna
> ----- Original Message -----
> From: "Martin Schayna" <mschayna@aktis.cz>
> From: "Roman Macura" <delphi@atlascon.cz>
> My to resime tak ze tech par cizich klicu "sama na sebe" pridavame
> na tabulku az _po_ nahrani dat, napr:
>
> ALTER TABLE Divisions
> ADD FOREIGN KEY (Parent_ID) REFERENCES Divisions (ID);
>
> Toto reseni name problemy co popisuje Pavel.
>
> Martin Schayna
Odpovedá: Roman Macura
17. 12. 2002 15:24
To se da vyresit vzory pro ruzne verze IB, i kdyz samozrejme
treba vzorova data v xml, nebo v bin. souborech jsou lepsi - vyreseno to
mame taky,
ale pri mnozstvi dat, ktera jsou v te stare databazi, trvaji obe varianty
neunosne dlouho.
Ale jinak - vsechno je to spatny zpusob, kdyz si uvedomis narocnost tveho
(i meho) reseni oproti logickemu pozadavku restrukturalizace.
No nic. Muzes mi rict jestli pouzivate normalne INSERT a TIBSql/TQuery nebo
prave ten TIBBatchRawFile?
----- Original Message -----
From: "Martin Schayna" <mschayna@aktis.cz>
To: <delphi-l@clexpert.cz>
Sent: Tuesday, December 17, 2002 2:51 PM
Subject: Re: IB - Drop foreign key constraints
----- Original Message -----
From: "Roman Macura" <delphi@atlascon.cz>
> Jo, tak to dela i IBPump, je to dobre reseni (sice nevim jak to dela, kdyz
> to bez logout/login nejde - jak uz tady bylo psano),
> az na to, ze ne pro muj dotaz Nemuzu cistou databazi, do ktere bych
> prenasel data ze stare, vytvorit ze skriptu
> (coz predpokladam delas Ty a pote do-tvoris ty foreign key), protoze nase
> vzorova db neni cista, ale obsahuje nejake male mnozstvi dat (bloby,
apod.).
Ano, generujeme ji ze skriptu a take do ni nahraveme vychozi data
(i bloby) samozrejme ne pomoci standardniho SQL ale pomoci vlastniho
nastroje ktery umi nahrat data do tabulky z binarniho streamu (muze
proto obsahovat i bloby). Pak nahravame uzivatelska data podobnym
zpusobem avsak se zohlednenim zmen ve strukture. Na zaver se
pripoji prave ty problematicke referencni integrity.
>
> Takze kdyz pouziju vzor (existujici db), tak i kdyz nebudu
> restrukturalizovat celou db, ale prenaset data,
> tak stejne potrebuju udelat drop tech klicu "sama na sebe" a to opet v
> jednom pripojeni nejde. To je pekne na h...
Vzorova databaze je IMHO spatny zpusob, co kdyz ma klient
jiny IB server -- s jinou ODS nebo na jine platforme.
> Trapný dotaz: Jak narocne bude pro databazi provest 40x login a logout,
> abych ty klice v klidu smazal?
> Nebo: Lze tedy nejak pracovat s metadata cache, nebo je to fakt marné?
Podle me budes mit problem -- jinak se chova napr. FB a IB. Na FB
se aplikace uplne odloguje, ale stejne si server databazi (nejakou dobu)
pridrzuje.
Martin Schayna
> ----- Original Message -----
> From: "Martin Schayna" <mschayna@aktis.cz>
> From: "Roman Macura" <delphi@atlascon.cz>
> My to resime tak ze tech par cizich klicu "sama na sebe" pridavame
> na tabulku az _po_ nahrani dat, napr:
>
> ALTER TABLE Divisions
> ADD FOREIGN KEY (Parent_ID) REFERENCES Divisions (ID);
>
> Toto reseni name problemy co popisuje Pavel.
>
> Martin Schayna
Odpovedá: Martin Schayna
17. 12. 2002 16:17
----- Original Message -----
From: "Roman Macura" <delphi@atlascon.cz>
> To se da vyresit vzory pro ruzne verze IB, i kdyz samozrejme
> treba vzorova data v xml, nebo v bin. souborech jsou lepsi - vyreseno to
> mame taky,
> ale pri mnozstvi dat, ktera jsou v te stare databazi, trvaji obe varianty
> neunosne dlouho.
>
> Ale jinak - vsechno je to spatny zpusob, kdyz si uvedomis narocnost tveho
> (i meho) reseni oproti logickemu pozadavku restrukturalizace.
To je otazka jak casto se zmena strukturu dela. My mame (v podstate) balickovy
soft, alespon v tom smyslu ze databaze vsech zakazniku ve stejne verzi programu
maji stejnou strukturu. Potreba zmenit strukturu je tehdy, pokud zakaznik
prejde
z nizsi verze programu na vyssi, a to jen tehdy pokud se struktura menila.
V ustalenem prostredi je to tak max. jednou za pul roku az rok -- pak si
skutecne
pocka par hodin (podle velikosti dat) na obnovu databaze do nove verze.
> No nic. Muzes mi rict jestli pouzivate normalne INSERT a TIBSql/TQuery nebo
> prave ten TIBBatchRawFile?
INSERTy pomoci TIBSQL. Mas lepsi zkusenosti s TIBBatchRawFile?
Martin Schayna
Odpovedá: Roman Macura
17. 12. 2002 16:05
Nevim jak tobe, ale mi pul roku (jako zakaznikovi) utece jako voda
Pomoci TIBBatch... jsem kdysi davno zkousel prenos velkeho mnozstvi dat
jednoduche tabulky a rychlost byla dramaticky vyssi nez pres TIBSql.
Ale prave jsem si ted nebyl jisty, co to udela na pomerne hodne provazanych
tabulkach.
> To je otazka jak casto se zmena strukturu dela. My mame (v podstate)
balickovy
> soft, alespon v tom smyslu ze databaze vsech zakazniku ve stejne verzi
programu
> maji stejnou strukturu. Potreba zmenit strukturu je tehdy, pokud zakaznik
prejde
> z nizsi verze programu na vyssi, a to jen tehdy pokud se struktura menila.
> V ustalenem prostredi je to tak max. jednou za pul roku az rok -- pak si
skutecne
> pocka par hodin (podle velikosti dat) na obnovu databaze do nove verze.
> > No nic. Muzes mi rict jestli pouzivate normalne INSERT a TIBSql/TQuery
nebo
> > prave ten TIBBatchRawFile?
> INSERTy pomoci TIBSQL. Mas lepsi zkusenosti s TIBBatchRawFile?
> Martin Schayna
Odpovedá: Richard Kejval
18. 12. 2002 9:34
Ahoj,
1. obecne to delame tak, ze predlohu zabalime a rozbalime,
ale neaktivujem indexy.
2. Deaktivace triggeru:
update rdb$triggers a
set
a.rdb$trigger_inactive=1
where
(a.rdb$trigger_inactive=0) and
(a.rdb$system_flag=0)
3. Prenos dat
4. Aktivace primarnich klicu:
update rdb$indices c
set
c.rdb$index_inactive=0
where
c.rdb$index_name in (
select b.rdb$index_name
from rdb$relation_constraints a
inner join rdb$indices b on (b.rdb$index_name=a.rdb$index_name)
where
(a.rdb$constraint_type='PRIMARY KEY') and
(b.rdb$index_inactive=1)
)
5. Aktivace ostatnich indexu
update rdb$indices c
set
c.rdb$index_inactive=0
where
c.rdb$index_inactive=1
6. Aktivace triggeru
A melo by to byt bez problemu.
S pozdravem
ing. Richard Kejval
IC Software s.r.o
Mobil: +420602477679
> Jo, tak to dela i IBPump, je to dobre reseni (sice nevim jak to dela, kdyz
> to bez logout/login nejde - jak uz tady bylo psano),
> az na to, ze ne pro muj dotaz Nemuzu cistou databazi, do ktere bych
> prenasel data ze stare, vytvorit ze skriptu
> (coz predpokladam delas Ty a pote do-tvoris ty foreign key), protoze nase
> vzorova db neni cista, ale obsahuje nejake male mnozstvi dat (bloby,
apod.).
>
> Takze kdyz pouziju vzor (existujici db), tak i kdyz nebudu
> restrukturalizovat celou db, ale prenaset data,
> tak stejne potrebuju udelat drop tech klicu "sama na sebe" a to opet v
> jednom pripojeni nejde. To je pekne na h...
>
> Trapný dotaz: Jak narocne bude pro databazi provest 40x login a logout,
> abych ty klice v klidu smazal?
> Nebo: Lze tedy nejak pracovat s metadata cache, nebo je to fakt marné?
>
>
> ----- Original Message -----
> From: "Martin Schayna" <mschayna@aktis.cz>
> To: <delphi-l@clexpert.cz>
> Sent: Tuesday, December 17, 2002 2:12 PM
> Subject: Re: IB - Drop foreign key constraints
>
>
> ----- Original Message -----
> From: "Roman Macura" <delphi@atlascon.cz>
> > Nemate nekdo nejaky lepsi navrh, jak aktualizovat databazi u zakaznika
> > na novou verzi struktury (nutnost zachovani dat)?
> >
> > Prozatim to delame pomoci presunu dat do nove ciste struktury pres SQL.
> > TIBBatchRawFile bude asi rychlejsi, ale muzu pomoci nej prenest data
jedne
> > tabulky
> > tvorici strom? (vazba tabulky sama na sebe - prozatim to resime jednou
> > ulozenou procedurou,
> > ktera nam vrati zaznamy v odpovidajicim poradi pro spravny insert)...
>
> My to resime tak ze tech par cizich klicu "sama na sebe" pridavame
> na tabulku az _po_ nahrani dat, napr:
>
> ALTER TABLE Divisions
> ADD FOREIGN KEY (Parent_ID) REFERENCES Divisions (ID);
>
> Toto reseni name problemy co popisuje Pavel.
>
> Martin Schayna
>
>
>
>
>
>